Image processing has become a commonplace activity due to the ease and availability of the hardware and software used to capture images. The popularity and accessibility of the Internet, and more importantly the creation of the World Wide Web, have greatly increased the use of images. However, the processing of captured images and other graphical elements is generally more complex as compared to the processing of textual data. For example, color images may need to be color matched between a video display and a printer, edge enhanced to extract certain features, and so on. Such manipulations tend to be CPU intensive, and because of the large amounts of data typically associated with image files, especially color images, such manipulations also tend to be I/O intensive. One area that is affected by the increased use of images, for example, is the preparation and printing of documents containing such images.
Because of the availability of sophisticated word processing and other desktop publishing programs, documents generally no longer consist solely of text data, but rather include a variety of images. Preparing such documents for printing on a computer may require several image processing operations including scaling, clipping, sharpening, various transformations and the like. These operations are performed either by the application or by printer driver software normally included with the printer. As a consequence of incorporating images into a document, the computer system will experience a high degree of loading due to the processing of the large amounts of data, typical of graphical image elements. Several approaches to document preparation and printing exist.
Some applications prepare a device independent bitmap of an image of the document to be printed. The bitmap is then sent to a printer via its corresponding printer driver software. In most cases, the application has no knowledge of the printer's requirements. For example, a user may decide to print a medium quality image using a certain kind of paper. This requires that an image of the document be created with a certain resolution and bit depth. The application cannot determine the resolution and/or bit depth needed to render output in accordance with the print parameters selected by the user. Such knowledge is contained in the printer driver. The application, having to accommodate any kind of printer, therefore takes a conservative approach and sends a copy of a high resolution bitmap of the image to the printer driver. The printer driver then performs additional processing (e.g. decimation) on the received copy of the high resolution image to generate output for the printer at the appropriate resolution.
This simple approach is a very inefficient way of printing. The application always generates a high resolution copy of the document regardless of the printer and the selected print parameters. This translates to the unnecessary processing of large amounts of data, requiring excessive disk activity as intermediate files are created, written out to the disk, read in from the disk, processed, written back out to the disk and so on. Such activity adversely impacts the user since access to the CPU is blocked until the print job has completed.
In another approach, the document processing application queries the printer driver to determine what image processing capabilities exist in the printer driver. The application then decides how to divide up the image processing tasks between the application and the printer driver. The application produces an appropriate image of the document and sends a copy of the image to the printer driver. The printer driver performs any required additional processing on the copy of the received image and outputs a final printer image of the document to the printer. Knowing the image processing capabilities of the printer driver improves efficiency, since printer-specific processing such as output resolution generation is performed by the printer driver. The application no longer needs to generate a high resolution bitmap in an attempt to accommodate all printers. Rather, the application performs only device-independent operations such as clipping, red-eye correction, sharpening, etc., operations not typically supported by the printer driver. This results in a smaller image file that is then passed from the application to the driver. From the standpoint of the user, however, the CPU still is tied up until the application has processed the image and passed a copy of the image to the printer driver, at which point the printer driver performs additional printer-specific processing on the received copy of the image and outputs the generated printer image to the printer.
To alleviate the waiting, most computers use a technique known as spooling to return the CPU to the user as quickly as possible from a print job. The printer image, i.e. the bitmap image that is actually sent to the printer, is copied out to the disk and sent to the printer as a background process. This allows the printer driver to return control of the computer back to the user without having to wait for the actual output to be produced. However, transmitting the final printer image to the printer quite often represents only a small fraction of the total effort of the print job, most of the effort and time being expended both by the application and the printer driver to produce the printer image of the document in the first place.
One operating system has taken the spooling technique one step further. Under the Microsoft.RTM. Windows '95 operating system, a method known as enhanced metafile format (EMF) spooling was implemented. With EMF spooling, the operating system (OS) spools up all of the calls that the application makes to the printer driver to a spool file, much in the same way that a printer image is presently spooled. The OS then plays back the spooled file, sending the spooled information to the printer driver, thus completing the print job entirely in the background. Control of the computer is returned to the user sooner under EMF spooling, since the user no longer must wait for the printer driver to perform its image processing operations.
Yet, even with EMF spooling, there still are factors which impact system performance during printing. Most notably is the fact that large amounts of data are being passed through the system. For example, consider a 24-bit color digitized image of an 8".times.10" photograph. Roughly 20 megabytes of data are needed to represent such an image at 300 dpi and 80 megabytes of data at 600 dpi. With EMF spooling, the OS spools up the calls made to the printer driver from the application, along with a copy of the 20 or 80 megabytes of data that represent the image. The spooled file is written to disk. During playback, the spooled file (which includes the 20 megabytes of image data) is read back from the disk and handed to the printer driver. As the printer driver prepares the printer image, temporary files are created, stored on the disk, read from the disk, written back out to the disk and so on. All of this disk activity takes its toll in the response time and overall performance of the OS. What the user perceives is a very slow and otherwise non-responsive system.
While the foregoing discussion has focused on the bottlenecks experienced during the processing of a print job, similar bottlenecks exist in the processing of images in general. What is needed is a method and system which minimizes the amount of data being passed by the OS during the handling and processing of images. In particular, a method and system is needed to more efficiently process a print job. It is also desirous to minimize the disk activity experienced by the OS during the processing of an image, such as during a print job.